Developer CD Series 1993…ch: Other People's Memory/ADC Developer CD (1993-03) (''Other People's Memory'')_iso/Dev.CD Mar 93.iso/Development Platforms/CSMP Digests/csmp-v1-015.txt

Text File | 1992-11-18 | 55.2 KB | 1,605 lines | [TEXT/MPS ]

C.S.M.P. Digest             Fri, 13 Mar 92       Volume 1 : Issue 15

Today's Topics:

     How do I grey out a 'static text' item in a DLOG?
    Prograph Summary
    GetNewMBar causes bus errors?
    ETO#6 ships
    Graf3d question
    TCL Application projects
    DiskVars / JRdData  ($22E)
    My INIT and cdev don't talk to each other!


The Comp.Sys.Mac.Programmer Digest is moderated by Michael A. Kelly.

These digests are available (by using FTP, account anonymous, your email
address as password) in the pub/mac/csmp-digest directory on ftp.cs.uoregon.
edu (try skinner.cs.uoregon.edu if that doesn't work).  This is also the home
of the comp.sys.mac.programmer Frequently Asked Questions list.

These digests are also available via email.  Just send a note saying that you
want to be on the digest mailing list to [e-mail], and you will
automatically receive each new digest as it is created.

The articles in these digests are taken directly from comp.sys.mac.programmer.
They are not edited; all articles included in this digest are in their original
posted form.  The only articles that are -not- included in these digests are
those which didn't receive any replies (except those that give information
rather than ask a question).  All replies to each article are concatenated
onto the original article in the order in which they were received.  Article
threads are not added to the digests until the last article added to the
thread is at least one month old (this is to ensure that the thread is dead
before adding it to the digests).

Send administrative mail to [e-mail].

-------------------------------------------------------

From: [e-mail]
Subject:  How do I grey out a 'static text' item in a DLOG?
Date: 25 Jan 92 19:55:16 GMT
Organization: Research Computing Center, Moscow State University

In article <[e-mail]>
[e-mail] ([e-mail] (Jeff E Mandel)) writes:
>To give your app that System 7 look, check the pixel Depth, and if 8 (or
>greater), do this:
>
>        RGBColor fc,gray={0x9999,0x9999,0x9999};
>        GetForeColor(&fc);
>        RGBForeColor(&gray);
>        DrawText (&itemData, 0, dataLen);
>        RGBForeColor(&fc);

I think there is a better way of getting something gray. If you want to  gray
 a text there's a special text mode in System7 (textGrayishOr = 49).  Or  you
 can use the following algorithm.

Suppose you want to "gray" something in the rect 'rect'

void MakeGray(???)
{
  RGBColor fColor, bColor;
  Rect     rect;

  GetForeColor(&fColor); GetBackColor(&bColor);
  if (GetGray(GetMaxDevice(&rect), &fColor, &bColor)) {
    RGBForeColor(&fColor);
    DrawSmth();
  }
}

Believe this would help, if you could only understand my English
Paul Kurzaev
Russia, Moscow University Computer Center
AppleLink: MOSCOW.UNIV
eMail:     [e-mail]



---------------------------

From: [e-mail] (Eric Winter)
Subject: Prograph Summary
Date: 6 Feb 92 14:55:04 GMT
Organization: Information Dimensions, Inc.

A couple of weeks ago I posted a request for experiences with Prograph 2.5.
Below is a summary of the responses I received as promised.

Tim Bates writes:
   >Eric,
   >Prograph is great. If you are interested in it you may want to
   >be know that there is a usenet mail list for prographers the address
   >for subscriptions is:
   >
   >
   >[e-mail]
   >
   >The TGS people are also contactable over the net.

James J. Coons writes:
   >I have used Prograph since its first release and I  very highly recommend
   >it. It is fully object oriented unlike Serius. Unlike Serius Prograph is
   >a complete programming language with complete access to Macintosh Toolbox.
   >It was selected as the best Macintosh development system by MacUser 2
   >years ago and has been improved greatly since then. It was nominated again
   >this year for the best development system, and really should win since it
   >is much better than any other development system out.  The company
   >which produced it TGS  provides excellent support.  It is fully system
   >7 compatable, supporting all system 7 features.  With inexpensive add ons
   >you can use external code written in C, Pascal or Fortran if you need to.
   >In my opinion Prograph is the best tool available on any computer in any
   >category! Also every other person I know who has used it agrees with that
   >assessment. Highly Recommended. The current version 2.5 supplies a
database
   >engine a class library of interface objects (Somewhat similar to
MacApp
   >or TCL). Prograph is a visual, object-oriented, data-flow language.
It is
   >very interactive, For instance you can graphically edit your user
interface,
   >or change your code, even while you are in the middle of an
execution. If
   >you change code in a routine which you have already executed it will
just
   >roll back the execution to that point and continue.  It has a full
680x0
   >compiler, interpreter/editor.  It is very bug free, the language is
fun.
   >What more can I say. Contact TGS at:
   >
   >   Voice:          800-565-1978 or 902-455-4446
   >   Fax :           902-455-2246
   >   Address:        2745 Dutch Village Road, Suite 200
   >                   Halifax, Nova Scotia,
   >                   Canada B3L 4G7
   >   Apple Link:     TGS.Systems
   >   America Online: Prographer
   >   Compuserve:     73300,3460
   >   EMail:            [e-mail]
   >   Modem:          902-455-6616
   >
   >I have no conection with TGS except as a very satisfied customer.
   >James J. Coons
   >[e-mail]

Robert Patt-Corner writes:
   >From: nimbus![e-mail] (Robert Patt-Corner)
   >
   >In article <[e-mail]>, [e-mail]
   >(Viraf Bankwalla) writes:
   >>
   >> Hi,
   >>
   >>   Has anyone used Serius Programmer/Developer and/or Prograph ?
   >>
   >>   What is the difference between the two ?  What languages do they
   >>   support ?  How extensive are the modules provided by them ? ....
   >
   >
   >I've very minimally looked at S/Prog and Prograph.  More serious
discussions
   >can be found in MACDEV on Compuserve.
   >
   >The main difference I see is in their level of granularity.
Prograph is a
   >real programming environment, and its primitives are fairly
primitive.  This
   >makes it harder to build something that works, and far easier to
build
   >something that you like or want or need.
   >
   >Serius supplies more fully formed objects at a lower level of
granularity.
   >Easier to cobble them together, harder to do what you want to do.
   >
   >Both have the liability of being non-portable.
   >

>/*---------------------------------------------------------------------
- ----*/
   >From: [e-mail]
   >
   >In article <[e-mail]> you write:
   >>Hi,
   >>
   >>  Has anyone used Serius Programmer/Developer and/or Prograph ?
   >>
   >>  What is the difference between the two ?  What languages do they
   >>  support ?  How extensive are the modules provided by them ? ....
   >>
   >>  Any info on the above would be appreciated.
   >>
   >>  Thanks in advance.
   >>
   >>  viraf bankwalla
   >>  [e-mail]
   >>  ...!uunet!gwusun!viraf
   >
   >I have purchased Serius. I am not really happy with it. You
   >can not create runtime objects, so that any application built
   >with it can not build new windows, for instance. What if the
   >user wants to keep hitting cmd-N for new windows within your
   >application? That would be a problem. Other SERIUS limitations
   >include an iconic metaphor which is not well-handled. You end
   >up with a lot of spaghetti-looking connections on your screen.
   >The startup sequence takes forever. There are many
   >limitations. I just use SuperCard 1.6 , which is by FAR the
   >most expandable, error-tolerant, and flexible tool for quick,
   >functional applications.
   >    I would love to try ProGraph, but I can not afford it
   >right now. Perhaps in a month or 2 I can share with you
   >something about it. It Does have an obj-oriented structure
   >which is much more hierarchical than SERIUS, but that also
   >means that the developer must be a bit more savvy in his/her
   >development specifications. Good Luck!
   >
   >    warm regards,
   >    Frank Ricardo


--
Eric Winter, Software Developer
Information Dimensions, Inc.
5080 Tuttle Crossing Blvd.
Dublin, OH  43017



---------------------------

From: [e-mail] (Jim Cook)
Subject: GetNewMBar causes bus errors?
Date: 27 Jan 92 02:03:43 GMT
Organization: Prime Computer, Inc.

Okay, this used to work under Think 4.0.  Now it fails under Think 5.0.

I am writing my first original(!) Mac application using Think C 5.0 on
my Mac IIx running 6.0.3.  I get hung up at the call to GetNewMBar with
a bus error.  Heck if I can figure it out.  So I go find the "Timer" program
from Cartwright & Reed (Mac Programming Primer in Think C) which does this
and worked fine last I checked when I had 4.0.  I recompile it as it was last
compiled under 4.0, correct a few mistakes (a few typecasts are now necessary),
and bam, it now fails the same way.  So I go to work, put it on my Mac II
running Think C 5.0 under 7.0.  I even force a recompile.  Bam, same problem
again.

There must be something simple I am missing here.
(I'll leave it until after I know the answer before I decide whether or not
to flame about running into it).

Thanks,
Jim
<[e-mail]>




- -------------------------

From: [e-mail] (Paul A. Pelton)
Subject:  GetNewMBar causes bus errors?
Date: 28 Jan 92 02:30:05 GMT
Organization: The TeleSoft BBS and Public Access Unix, [phone]

Can you post a sample of the offending code? I'd be interested to see what's
going on. Also, check to make sure that the MBAR resource is actually there
(obvious, I know).

Paul



- -------------------------

From: [e-mail] (Jim Cook)
Subject:  GetNewMBar causes bus errors?
Date: 28 Jan 92 14:33:52 GMT
Organization: Prime Computer, Inc.

In article <[e-mail]> I wrote:

>Okay, this used to work under Think 4.0.  Now it fails under Think 5.0.
>
>I am writing my first original(!) Mac application using Think C 5.0 on
>my Mac IIx running 6.0.3.  I get hung up at the call to GetNewMBar with
>a bus error.  Heck if I can figure it out.  So I go find the "Timer" program
>from Cartwright & Reed (Mac Programming Primer in Think C) which does this
>and worked fine last I checked when I had 4.0.  I recompile it as it was last
>compiled under 4.0, correct a few mistakes (a few typecasts are now
necessary),
>and bam, it now fails the same way.  So I go to work, put it on my Mac II
>running Think C 5.0 under 7.0.  I even force a recompile.  Bam, same problem
>again.

The answers to these problems are as follows:

>From America On-Line (AOL), I downloaded a file describing the changes
necessary to run Macintosh Programming Primer programs under Think 5.0.
For the Timer program, there were a few casts to be added (which I had
already figured out from the compiler error messages) and a #include of
"Packages.h" at the top.  The include solved the problem in Timer with
GetNewMBar, although I don't know why.  The purpose of include was to
declare some GetIUString routines used with getting the time.  I don't
think these routines had not been called (or miscalled when Packages
wasn't there) yet when GetNewMBar was called, so nothing was messed up
yet, so why was GetNewMBar failing?  <Shrug>.

With regard to my problem, based on my previous compiler experience, I
created a small test program - just a bunch of init calls (InitGraf, etc.)
and the call to GetNewMBar.  When I pasted in the resources from Timer,
it worked.  When I pasted in the resources from my program, it failed.
A mention of this problem in a call to Symantec tech support produced
the quick response that there is a bug in ResEdit 2.1.1.  Sure enough,
open up your menu bar resources.  Double click on resource 129.  Now
pull down "Get MENU & MDEF info..." from MENU on the menu bar.  It says
the MENU id is 401 (not 129), and the MDEF number is 1 (not 0).  Gee,
that's not what the earlier menus said...

The minor flame I have here is that GetNewMBar should not fall over with
a bus error or a divide by zero or ... when it fails due to missing MENU
resources or references to non-existant MDEF resources in MENU resources.
It should simply return a null pointer.

Thanks to all and Symantec,
Jim
<[e-mail]>



- -------------------------

From: [e-mail] (Steven Ritter)
Subject:  GetNewMBar causes bus errors?
Date: 28 Jan 92 16:15:27 GMT
Organization: Doctoral student, Psychology, Carnegie Mellon, Pittsburgh, PA

>The minor flame I have here is that GetNewMBar should not fall over with
>a bus error or a divide by zero or ... when it fails due to missing MENU
>resources or references to non-existant MDEF resources in MENU resources.
>It should simply return a null pointer.

This would be a minor flame if it was only GetNewMBar that failed to
check for errors, but the entire Mac OS is written this way.  Any
routine that allocates memory will crash if it can't find the memory
(you only get error #25 if you're lucky).  How hard would it be to
return a null pointer if a NewXXX routine couldn't get memory?  Pass a
bad argument to just about any system call, and you're playing with
fire.  God forbid you should call InvalRect when the current GrafPort is
not a window.

All of this stuff wouldn't be too bad if there was protected memory and
your program simply crashed, but, on the Mac, one bad program does spoil
the whole bunch.

Steve



- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject:  GetNewMBar causes bus errors?
Date: 29 Jan 92 14:18:33 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (Steven Ritter) writes:
>This would be a minor flame if it was only GetNewMBar that failed to
>check for errors, but the entire Mac OS is written this way.  Any
>routine that allocates memory will crash if it can't find the memory
>(you only get error #25 if you're lucky). How hard would it be to
>return a null pointer if a NewXXX routine couldn't get memory?

Most NewXXX calls do exactly that, last time I checked.

>Pass a
>bad argument to just about any system call, and you're playing with
>fire.  God forbid you should call InvalRect when the current GrafPort is
>not a window.

There's only so much checking you can reasonably do. I don't think you'd want
to use a Mac with *really* strict error checking. Every QuickDraw routine would
begin by checking that A5 is even and points to an address in the heap. Then,
it would have to check that A5^ is even and points to an address in the heap...
you get the idea. As soon as an Operating System puts major data structures
(GrafPorts, TERecs) in unprotected memory, total error checking is no longer
realistic.

>All of this stuff wouldn't be too bad if there was protected memory and
>your program simply crashed, but, on the Mac, one bad program does spoil
>the whole bunch.

To be fair, you should mention that MultiFinder has improved in getting rid of
crashed applications. A bus error usually is not much of a problem.

Matthias

- ---
Matthias Neeracher                                   [e-mail]
 "You must have picked up that copy of Scarlett instead of Inside Mac
  when you tried to find the right call..." -- Keith Rollin



- -------------------------

From: [e-mail] (Pete Gontier)
Subject:  GetNewMBar causes bus errors?
Date: 31 Jan 92 04:50:13 GMT


 MU> In article <[e-mail]> [e-mail]
 MU> (Steven Ritter) writes:

 MU> >This would be a minor flame if it was only GetNewMBar that failed to
 MU> >check for errors, but the entire Mac OS is written this way...

 MU> >Pass a bad argument to just about any system call, and you're playing
 MU> >with fire.

 MU> There's only so much checking you can reasonably do. I don't think you'd
 MU> want to use a Mac with *really* strict error checking. Every
 MU> QuickDraw routine would begin by checking that A5 is even and points
 MU> to an address in the heap...

Ack! Certainly not.

It's not the responsibility of a routine to make sure
it's called in the right context. That's the caller's problem. What irks
me is that when GetNewDialog returns nil, there's any of a zillion reasons
why, and all I can do is dumbly return a kNilPointerErr. Every time I do
it, I think "Boy, the user'll really love THIS one..." Unless the program
can tell the user what went wrong, there is 0% chance the user can help
recover from the error.

 MU> As soon as an Operating System puts major data structures
 MU> (GrafPorts, TERecs) in unprotected memory, total error checking is no
 MU> longer realistic.

If you're talking about total error checking of the kind used in software
for medical equipment, you're right. They do real fun stuff like range-check
two numbers before adding them together -- as a matter of course.
("Whoever calls this routine could be an idiot, and someone's life is in
the balance -- let's check the parameters.") But for Macintosh
business application software and the like, I think it's better to simply
   1) commit your soul to good code
   2) debug
 * Origin: EC Technology, Santa Barbara, CA (1:109/70.811)



- -------------------------

From: [e-mail] (Jon W{tte)
Subject:  GetNewMBar causes bus errors?
Date: 2 Feb 92 11:59:35 GMT
Organization: Royal Institute of Technology, Stockholm, Sweden

> [e-mail] (Pete Gontier) writes:

    MU> want to use a Mac with *really* strict error checking. Every
    MU> QuickDraw routine would begin by checking that A5 is even and points
    MU> to an address in the heap...

   it's called in the right context. That's the caller's problem. What irks
   me is that when GetNewDialog returns nil, there's any of a zillion reasons
   why, and all I can do is dumbly return a kNilPointerErr. Every time I do

How about

Boolean
ValidateDialog ( long type , short ID )
{
    Handle h ;

    if ( ! GetResource ( type , ID ) ) {
        return 0 ;
    }
    if ( ! GetResource ( 'DITL' , ID ) ) {
        return 0 ;
    }

    return 1 ;
}

which does a simple test. Then check if memory is OK (less than
2 ks contigous and you could be sure it's memory)

--
This Signature is distributed under the conditions of the Signature License,
available at a fee from   [e-mail]  (Jon W{tte)  Reading the Signature
implies that you accept to be bound by the terms in said License. Should you
not agree on any of these terms, you must return the Signature unread to me.



- -------------------------

From: [e-mail] (Bernie Wieser)
Subject:  GetNewMBar causes bus errors?
Date: 2 Feb 92 17:58:19 GMT
Organization: The University of Calgary, Alberta, Canada

So why isn't ResError being checked?  My code usually looks like
    somehandle = SomResourceCall();
    if(!(err=ResError()) && somehandle)
        {
        BarfError(err);
        }
You could even add another brick with MemError().


--



- -------------------------

From: [e-mail] (Keith Rollin)
Subject:  GetNewMBar causes bus errors?
Date: 3 Feb 92 18:24:03 GMT
Organization: Apple Computer Inc., Cupertino, CA

In article <[e-mail]> [e-mail] (Jon W{tte) writes:
>> [e-mail] (Pete Gontier) writes:
>
>   What irks
>   me is that when GetNewDialog returns nil, there's any of a zillion reasons
>   why, and all I can do is dumbly return a kNilPointerErr. Every time I do
>
>How about
>
>Boolean
>ValidateDialog ( long type , short ID )
>{
>    Handle h ;
>
>    if ( ! GetResource ( type , ID ) ) {
>        return 0 ;
>    }
>    if ( ! GetResource ( 'DITL' , ID ) ) {
>        return 0 ;
>    }
>
>    return 1 ;
>}
>
>which does a simple test. Then check if memory is OK (less than
>2 ks contigous and you could be sure it's memory)

Necessary, but not sufficient. You also have to check for all the
CDEF's, icons, PICTs, dctb's, ictb's, actb's, pllt's, etc., to be
loaded, and for all the control records, window records, text edit
records, etc., to be created.

--
- ----------------------------------------------------------------------------
Keith Rollin           ---            <Taligent .signature under construction>
Disclaimer: Pretty soon, I really _won't_ be speaking for Apple...



- -------------------------

From: [e-mail] (Ben Hekster)
Subject:  GetNewMBar causes bus errors?
Date: 5 Feb 92 16:40:58 GMT
Organization: University of Twente, Dept. of Computer Science

In article <[e-mail]> [e-mail] (Keith Rollin) writes:
[...]
>Necessary, but not sufficient. You also have to check for all the
>CDEF's, icons, PICTs, dctb's, ictb's, actb's, pllt's, etc., to be
>loaded, and for all the control records, window records, text edit
>records, etc., to be created.

I noticed that under 7.0, CouldDialog and CouldAlert are also no longer
supported.  These could have been useful on 7.0 machines like the
PowerBooks, to ensure in advance that certain dialogs which are likely to
be needed do not wake up the sleeping hard disk later.

--
Ben `Hackster' Hekster            | sigblock(sigmask(SIGFLAME));
[e-mail]            | "Here we are now, entertain us"



- -------------------------

From: [e-mail] (Pete Gontier)
Subject:  GetNewMBar causes bus errors?
Date: 11 Feb 92  01:13:30 EST

 JW> From: [e-mail] (Jon W{tte)

 PG> What irks me is that when GetNewDialog returns nil, there's any of
 PG> a zillion reasons why, and all I can do is dumbly return a
 PG> kNilPointerErr.

 JW> How about
 JW>
 JW> Boolean
 JW> ValidateDialog ( long type , short ID )
 JW> {
 JW>     Handle h ;
 JW>
 JW>     if ( ! GetResource ( type , ID ) ) {
 JW>         return 0 ;
 JW>     }
 JW>     if ( ! GetResource ( 'DITL' , ID ) ) {
 JW>         return 0 ;
 JW>     }
 JW>
 JW>     return 1 ;
 JW> }

 JW> which does a simple test. Then check if memory is OK (less than
 JW> 2 ks contigous and you could be sure it's memory)

You *can* do this sort of thing. There's nothing wrong with it.
It's useful. You can also set up a ResErrProc which reports errs via
globals. It doesn't go far enough, of course. What if NewWindow or
NewControl fails? If and when they do, why did they? (I suppose I
shouldn't whine about this problem recursively, though.)

But more importantly, this sort of check misses the point. Only
GetNewDialog knows of all the possible errors that it might cause.
*I* shouldn't know. Not because of some magical allegiance to Apple's
authority on the matter, but because it's simply good design practice.

The EC in my tagline stands for "Error Checking." I'm a fanatic. The
toolbox should always return an error to me. It doesn't, and belly-aching
about it won't help. The sad part is that Pink won't be any better.
Anybody want to give me a job writing an OS from scratch?

 * Origin: EC Technology, Santa Barbara, CA (1:109/70.811)

 * Origin: EC Technology, Santa Barbara, CA (1:109/70.811)



- -------------------------

From: [e-mail] (Pete Gontier)
Subject:  GetNewMBar causes bus errors?
Date: 11 Feb 92  01:14:18 EST

 BW> From: [e-mail] (Bernie Wieser)

 BW> > So why isn't ResError being checked?  My code usually looks like
 BW> >    somehandle = SomResourceCall();
 BW> >    if(!(err=ResError()) && somehandle)
 BW> >        {
 BW> >        BarfError(err);
 BW> >        }

 BW> You could even add another brick with MemError().

Not such a hot idea. ResError has returned memory manager errors for
a long time now. If MemError is non-zero after a resource call, there's
no documented reason why.

 * Origin: EC Technology, Santa Barbara, CA (1:109/70.811)

 * Origin: EC Technology, Santa Barbara, CA (1:109/70.811)



---------------------------

From: [e-mail] (Kent Sandvik)
Subject: ETO#6 ships
Date: 4 Feb 92 18:54:04 GMT
Organization: MacDTS Mongols

Apologies if this sounds like advertisement, but I guess this
note is of some help to our developers, Kent:

- ----
Sub:    E.T.O. #6 Ships from APDA

The following product has started shipping from APDA:

Title:      E.T.O.: Essentials Tools Objects #6
- -------------------------------------------------
Description:
E.T.O. is the most complete and comprehensive collection of Apple development
tools ever combined in one package.  E.T.O. contains all the most widely used
Apple development tools on a CD-ROM disc, with hardcopy final documentation,
and is sold as a four-issue subscription.  E.T.O. includes:
- MPW development environment
- MacApp application framework
- MPW C++
- MPW C
- MPW Object Pascal
- MPW Assembler
- SADE
- SourceBug
- ResEdit, MacsBug, Virtual User, BalloonWriter, etc.
- Developer Essentials
- Selected pre-release versions of tools

What's New on E.T.O #6?
- MacApp 3.0b3
- New final releases of MPW C, Pascal, Assembler, Rez, DeRez, and other MPW
  components (in the Latest MPW folder)
- C++ 3.2b3 (final candidate)
- ToolServer 1.0b1
- MPW QR6 (Quarterly Release #6)
- SADE 1.3.1 final
- SourceBug 1.0 final
- Discipline 2.0.2 final
- Virtual User 1.1 final
- BallonWriter 1.0.1 final
- draft chapters of a revised edition of Inside Macintosh
- documentation on disc for SourceBug and a new MPW Command Reference
- a new Apple Event Registry document on disc (Winter 1992 edition)




- -------------------------

From: [e-mail] (Blair M. Burtan)
Subject:  ETO#6 ships (but no QuickTime)
Date: 11 Feb 92 23:43:56 GMT
Organization: Boston U. College of Engineering

Sigh.  I was looking forward to seeing some QuickTime stuff on this
disk but alas Apple has decided not to include anything. Sniff Sniff.
:-(
--
+---------------------------------------+
+ "If it isn't Baroque, don't fix it."  +
+               - Beauty and The Beast  +
+                        +
+ Blair M. Burtan: [e-mail]    +
+                  [e-mail]   +
+---------------------------------------+





- -------------------------

From: [e-mail] (Lawrence D'Oliveiro, Waikato University)
Subject:  ETO#6 ships (but no QuickTime)
Date: 12 Feb 92 01:42:47 GMT
Organization: University of Waikato, Hamilton, New Zealand

In article <[e-mail]>, [e-mail] (Blair M. Burtan)
complains about ETO #6 not containing any QuickTime stuff.

In that case, it looks like the only way to get the QuickTime documentation
is still to buy the developer kit from APDA, though I sincerely hope the US$195
price for this has some reasonable excuse, like royalties for the movies
on the CD.

You'd think, though, that it would be possible for Apple to make the
QuickTime documentation available on its own, at a much lower cost.

Lawrence, still waiting for his ETO #6.



- -------------------------

From: [e-mail] (Povl Hessellund Pedersen)
Subject:  ETO#6 ships (but no QuickTime)
Date: 12 Feb 92 17:18:29 GMT
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark

[e-mail] (Lawrence D'Oliveiro, Waikato University) writes:

>In article <[e-mail]>, [e-mail] (Blair M. Burtan)
>complains about ETO #6 not containing any QuickTime stuff.

>In that case, it looks like the only way to get the QuickTime documentation
>is still to buy the developer kit from APDA, though I sincerely hope the US$195
>price for this has some reasonable excuse, like royalties for the movies
>on the CD.

there is a few megabytes of compressed QuickTime developer notes available
on ftp.apple.com in a folder onder the QT folder. I have not looked at it,
but I think most of it is sample code and interface documentation.
The C package is 2+MB and the Pascal version << 1 MB.

Povl
--
Povl H. Pedersen (External student at dept. of CS, student at dept. economics)
Macintosh programmer, consultant and technical support
[e-mail]   /   [e-mail]



---------------------------

From: [e-mail] (Scott_Kovner-(EE'90))
Subject: Graf3d question
Date: 5 Feb 92 03:14:25 GMT
Organization: The Cooper Union ( NY, NY )

Where can I get documentation for Graf3d?

My compiler, THINK C, supplies the header files and libraries for
what appears to be a 3d graphics package called graf3d, but no
documentation.  I could use something of this sort.

Please email any info to [e-mail]
My news server often drops messages, which my mailer doesn't.

I will post a summary if the info seems important.

Thank you very much.

                Scott Kovner
                [e-mail]



- -------------------------

From: [e-mail] (Scott_Kovner-(EE'90))
Subject:  Graf3d
Organization: The Cooper Union ( NY, NY )
Date: Mon, 10 Feb 1992 23:14:48 GMT

Thank you to everyone who responded to my request for documentation on the
library Graf3d.  The responses were very helpful.

Here is the most complte response.  Using the sample code therein, I was
able to get a rotating cube on a Mac SE w/system 7 w/THINK C 5.0

One warning, the THINK C 5 doesn't appear to have a global variable
thePort3D.  simply use your own 3D PortHndl to some space you declare instead.
Also, I had to call InitGraf in addition to the 3d initialization stuff.

Thanx again to all of you.

>>From daemon Thu Feb  6 17:00 EST 1992
>>From <[e-mail]>  Thu Feb  6 16:59:33 1992 remote from milton.u.washington.edu
>Received: from milton.u.washington.edu by marvin.cooper.edu (5.61.3B2.1/1.34.1.2)
>    id AA11194; Thu, 6 Feb 92 16:59:33 -0500
>Received: by milton.u.washington.edu
>    (5.65/UW-NDC Revision: 2.22 ) id AA12775; Thu, 6 Feb 92 14:30:28 -0800
>Sender: [e-mail]
>Date: Thu, 6 Feb 1992 14:30:27 -0800 (PST)
>From: Thomas Busey <[e-mail]>
>Subject: graf3d docs
>To: [e-mail]
>Message-Id: <[e-mail]>
>Status: R
>
>Here are some docs that I downloaded some time ago.  The other info I
>found is in the MPW manuals.
>
>Tom Busey
>[e-mail]
>Graf3D and What I Discovered Therein.
>
>
>Some UseNetter's thought this might be beneficial to the net, so, here goes the
>first installment of "Graf3D and What I Discovered Therein."  Feel free to
>correct and dispute anything I say.  I'm not an expert programmer and only
>stumbled through Graf3D a year and a half ago.  Also, sorry, I don't know C.
>
>"Graf3D and What I Discovered Therein - Part1"
>==============================================
>Here are the following functions/procedures and data types that Graf3D defines:
>
>Data Types:
>  Fixed    (Essentially a LongInt <32-Bit> number where the high 16 bits
>            represent the integer portion of the number and the low 16 bits
>            represent the fractional portion of the number.  HiWord and LoWord
>            can be used to extract said portions.  To convert a LongInt to a
>            Fixed type, divide the LongInt by 65536 <2^16>)
>
>  Point3D   = RECORD
>               x:Fixed;
>               y:Fixed;
>               z:Fixed;
>            END;
>           (Note: Unlike the Point type, h and v are called x and y <and z>
>            and are of type Fixed instead of Integer.)
>
>  Point2D   = RECORD
>               x:Fixed;
>               y:Fixed;
>            END;
>           (Note: Why a Point2D and not just Point?  a- It uses the Fixed type
>            variable, and b- It is thus easy to convert between a Point3D and
>            Point2D for screen display.)
>
>  XfMatrix  = ARRAY [0..3, 0..3] of Fixed;
>           (This is the transformation matrix that Graf3D uses to rotate and
>            translate points.  If your familiar with the concepts and lingo
>            used in 3D graphics, you'll know all about the transformation
>            matrix.)
>
>  Port3DPtr = ^Port3D;
>  Port3D    = RECORD
>                GrPort: GrafPtr;
>                viewRect: Rect;
>                xLeft, yTop, xRight, yBottom: Fixed;
>                pen, penPrime, eye: Point3D;
>                hSize, vSize: Fixed;
>                hCenter, vCenter: Fixed;
>                xCotan, yCotan: Fixed;
>                ident: Boolean;
>                xForm: XfMatrix;
>              END;
>
>           (I'll discuss each of these fields to the Port3D in the next
>            installment.)
>
>  (Functions and Procedures)
>
>PROCEDURE InitGraf3D (GlobalPtr: Ptr);
>
>PROCEDURE Open3DPort (port: Port3DPtr);
>
>PROCEDURE SetPort3D (port: Port3DPtr);
>
>PROCEDURE GetPort3D (VAR port: Port3DPtr);
>
>PROCEDURE MoveTo2D (x, y: Fixed);
>
>PROCEDURE MoveTo3D (x, y, z: Fixed);
>
>PROCEDURE Move2D (dx, dy: Fixed);
>
>PROCEDURE Move3D (dx, dy, dz: Fixed);
>
>PROCEDURE LineTo2D (x, y: Fixed);
>
>PROCEDURE LineTo3D (x, y, z: Fixed);
>
>PROCEDURE Line2D (dx, dy: Fixed);
>
>PROCEDURE Line3D (dx, dy, dz: Fixed);
>
>FUNCTION Clip3D(src1, src2: Point3D; VAR dst1, dst2: Point);
>
>PROCEDURE SetPt3D (VAR pt3D: Point3D; x, y, z: Fixed);
>
>PROCEDURE SetPt2D (VAR pt2D: Point2D; x, y: Fixed);
>
>PROCEDURE ViewPort (r: Rect);
>
>PROCEDURE LookAt (left, top, right, bottom: Fixed);
>
>PROCEDURE ViewAngle (angle: Fixed);
>
>PROCEDURE Identity;
>
>PROCEDURE Scale (xFactor, yFactor, zFactor: Fixed);
>
>PROCEDURE Translate (dx, dy, dz: Fixed);
>
>PROCEDURE Pitch (xAngle: Fixed);
>
>PROCEDURE Yaw (yAngle: Fixed);
>
>PROCEDURE Roll (zAngle: Fixed);
>
>PROCEDURE Skew (zAngle: Fixed);
>
>PROCEDURE Transform (src: Point3D; VAR dst: Point3D);
>
>Whew!  That's it.  Most of this has come straight from the MPW documentation.
>I'll discuss each of these in following installments.  For now, you might note
>that many of these have direct QuickDraw counterparts (SetPt, InitGraf, etc...)
>that should make many of the procedures and functions almost self explanatory.
>
>Well, all for now!
>
>john calhoun
>
>
>
>Graf3D and What I Discovered Therein - part 2
>
>Yeah, part 1 was pretty much header info.  But, some people may not have it.
>Yes, I will present some code for setting up the 3D port and using it.  Wait
>until about part 4 or 5 or so.  This is preliminary stuff to avoid a lot of
>confusion later.
>
>The only variable type I skipped over last time was the Port3D record.  Here it
>is described:
>
>Fields of the Port3D;
>GPort      This is also documented as GrPort in the MPW docs.  In any event
>           it is a pointer to the grafPort associated with the 3D port.  Thus
>           standard Quickdraw calls to this port will show up with the 3D
>           calls.  Want your 3D to appear white on black?  You can just
>           InvertRect the portRect field of the G(r)Port field of your Port3D.
>
>viewRect   Viewing rectangle within the grafPort.  In the 3D-way of describ-
>           ing a 'point of view', this rectangle corresponds to the base of
>           the pyramid formed by the user's "eye" and the four corners of the
>           screen.
>
>xLeft,     World coordinates corresponding to the viewRect.  You shouldn't
>yTop,      have to manipulate these variables directly.  The procedures for
>xRight,    setting up the camera take care of these.
>yBottom
>
>pen        Like the Quickdraw pen, but with 3 dimensional coordinates.
>
>penPrime   The pen location as transformed by the xForm matrix.  Thus, calls
>           to Yaw, Roll, etc will affect this pen's location.  Again, you
>           shouldn't have to manipulate this variable.
>
>eye        When you call ViewAngle, this variable is established.  It repres-
>           ents the 3D point in space where the apex of the viewing pyramid
>           is fixed.
>
>hSize,     This will store the half-width and half-height of the viewRect in
>vSize      screen coordinates.
>
>hCenter,   Center of the viewRect in screen coordinates.
>vCenter
>
>xCotan,    Graf3D sets these up as viewing cotangents (when you call ViewAngle)
>yCotan     for calls to Clip3D.
>
>Ident      When TRUE, the transforming routines are skipped.  This is set to
>           TRUE when you set the xForm matrix to the identity matrix (non-
>           rotated).
>
>xForm      This is a 4x4 matrix of variables for transforming points.  All
>           calls to Yaw(), Roll(), etc are applied to this matrix and then
>           Graf3D uses the matrix to transform points in space.  Unless
>           reset by Identity, this matrix will continue to represent the net
>           result of all transformation calls.
>
>Setting up a port:
>As with programs using Quickdraw, a call to IntGraf3D(@thePort3D) must be made
>during the initialization portion of your program.  Here is how I've
>initialized my 3D port:
>
>var
>  gPort3D                   :Port3D;
>  gPort3DPtr                :Port3DPtr;
>  origin                    :Point3D;
>  viewScreen                :Rect;
>
>begin
>  InitGraf3D(@thePort3D);
>  Open3DPort(@gPort3D);
>  SetRect(viewScreen,100, 20, 348, 144);
>  ViewPort(viewScreen);
>  LookAt(-983040, 655360, 983040, -655360);
>  ViewAngle(1604480);
>  SetPt3D(origin, 0, 0, 0);
>  gPort3D.eye:= origin;
>  FillRect(gPort3D.viewRect, black);
>  ...
>end;
>
>This will set up a small 248x124 3D port in the center of a 7-inch Mac screen.
>As well, it sets the eye at the 'origin' in space looking straight ahead
>parallel to the "ground".  Finally it fills it black to look like outer space.
>Those lengthy numbers used in LookAt and ViewAngle are fixed type numbers.  The
>ViewAngle (1604480) for example, represents an angle of 24 degrees
>(1604480/65536).
>Perhaps this is a good time to explain the view angles.  The view angle defines
>the amount of perspective given to 3D points and lines when drawn to the
>screen.  An angle of 0 represents no perspective (or orthographic) projection.
>10 degrees is similar to the perspective seen through a telephoto lens, 25
>degrees is generally accepted as 'normal' perspective of the human eye, and 80
>degree would give you a distorted 'fisheye'-like wide angle perspective.
>
>Enough of Part 2.  Stay tuned for more.  Note: I can't get MAIL to work right.
>I can READ but can't reply.
>
>john calhoun
>
>
>Graf3D and What I Discovered Therein - part3
>
>Well, I must say I'm posting this all a piece at a time.  I don't have any of
>this written all out in one place.  So if you want this, here it is, capture
>it.  Also, I'll say again that I am not an expert with this at all.  I have
>only experimented with it for a couple of months back when I was first learning
>to program the Mac (and learning Pascal too).  So, feel free to post
>corrections of any of my errors and take my 'tutorial' as a starting point
>only.  I just saw all the confusion about Graf3D and thought, "Well, I could
>explain a little bit of it."
>
>Drawing in 3D-
>
>As I may have hinted at before, all drawing is done 'wireframe' with Graf3D.
>You set up a group of 3D points and use Move3D, MoveTo3D, LineTo3D, etc. to
>display your drawing.  I'm sure a guru could take the 2D equivalents of these
>screen points and create regions and paint them etc.  For my own purposes, this
>would clearly have been too slow.
>
>So, how did I optimize Graf3D within the bounds allowed by Graf3D?
>
>Setting up your 3D points-
>
>Consider a simple cube.  Counting up the vertices gives us 8 points.  If we set
>up an array [0..7] of Point3D, we can initialize all these points and then
>repeatedly connect-the-dots.  Calls to Yaw, Pitch, etc, and moving the 'eye'
>around in space will give us different views of this simple cube.
>
>The scale you use for the cube is fairly arbitrary.  Lets use a cube with a
>side of length 100 for simplicity.  In your initialization routine you caould
>call this:
>
>  var
>    cubeVertices: array [0..7] of Point3D;
>
>  begin
>    SetPoint3D(cubeVertices[0], 0, 0, 0);
>    SetPoint3D(cubevertices[1], 100, 0, 0);
>    SetPoint3D(cubeVertices[2], 100, 100, 0);
>    SetPoint3D(cubeVertices[3], 0, 100, 0);
>    SetPoint3D(cubeVertices[4], 0, 0, 100);
>    SetPoint3D(cubeVertices[5], 100, 0, 100);
>    SetPoint3D(cubeVertices[6], 100, 100, 100);
>    SetPoint3D(cubeVertices[7], 0, 100, 100);
>  ...
>  end;
>
>An alternate (and perhaps quicker) way of doing this would be to have set up an
>array of Fixed [0..7, 0..2].  This way, you never create the 3D points, but
>assign the x, y, and z coordinates of each verticee.  MoveTo3D and LineTo3D
>(etc) expect you to pass the fixed x, y, and z coordinates anyway.  Using
>Point3D's is convenient, but you'll still have to "dissect" the corrdinates out
>of these points when you call MoveTo3D, etc.
>
>A 'convenient' way around this hassle would be to create your own procedures:
>As an example:
>  Long way:
>
>    MoveTo3D(cubeVertices[i].x, cubeVertices[i].y, cubeVertices[i].z);
>
>  A nice procedure:
>
>    procedure MoveTo3DPt (thePoint: Point3D);
>    begin
>      MoveTo3D(thePoint.x, thePoint.y, thePoint.z);
>    end;
>
>    -now simply call-
>    MoveTo3DPt(cubeVertices[i]);
>
>I think I'll use this second way here.  (You could make a whole library of
>routines that translate 3D points, etc.)
>So, you've set up your 3D port (from part 2 of this little piece), and you've
>initialized the 8 vertices of your cube, - here is a simple loop to use the
>mouse to rotate the points from the perspective of the eye.
>
>var
>  mousePt:Point;     {A STANDARD QuickDraw point that is}
>
>{------}
>
>    procedure MoveTo3DPt (thePoint: Point3D);
>    begin
>      MoveTo3D(thePoint.x, thePoint.y, thePoint.z);
>    end;
>
>{------}
>
>    procedure LineTo3DPt (thePoint: Point3D);
>    begin
>      LineTo3D(thePoint.x, thePoint.y, thePoint.z);
>    end;
>
>{------}
>
>begin
>
>  ...
>
>  repeat
>    GetMouse(mousePt);
>    Roll((256 - mousePt.h) * 3276);  {3276 is about 1/10 of a degree, thus
>                                      on a 512 Mac screen, +/- 25 degrees
>                                      is your roll velocity}
>    origin.z:=origin.z+mousePt.v;    {We'll use the vertical position of the
>                                      mouse to change the z coordinate of
>                                      the origin (see part 2 for origin}
>    gPort3D.eye:=origin;             {Now we set the 'eye' of the 3D port
>                                      to the new location of the var origin}
>    FillRect(gPort3D.ViewRect, black);  {Erase other points drawn}
>    MoveTo3DPt(cubeVertices[0]);
>    LineTo3DPt(cubeVertices[1]);
>    LineTo3DPt(cubeVertices[2]);
>    LineTo3DPt(cubeVertices[3]);
>    LineTo3DPt(cubeVertices[0]);
>      {We have just drawn the bottom of the cube}
>    MoveTo3DPt(cubeVertices[4]);
>    LineTo3DPt(cubeVertices[5]);
>    LineTo3DPt(cubeVertices[6]);
>    LineTo3DPt(cubeVertices[7]);
>    LineTo3DPt(cubeVertices[4]);
>      {We have now drawn the top of the cube, now to connect the top & bot}
>    MoveTo3DPt(cubeVertices[0]);
>    LineTo3DPt(cubeVertices[4]);
>    MoveTo3DPt(cubeVertices[1]);
>    LineTo3DPt(cubeVertices[5]);
>    MoveTo3DPt(cubeVertices[2]);
>    LineTo3DPt(cubeVertices[6]);
>    MoveTo3DPt(cubeVertices[3]);
>    LineTo3DPt(cubeVertices[7]);
>  until button;     {clicking the mouse button exits the program}
>end.
>
>So, try that one out.  It's bits from a little test program I wrote.  You'll
>also have to have part 2 of my posts to do the port setting up stuff.  I'm
>hoping to that this is enough to get most everyone started.
>
>I could post more, but mostly program specific stuff.  I will say that my
>biggest annoyance with Graf3D was that it is difficult (impossible?) to
>actually rotate both the cube AND the eye at the same time.  As I recall,
>rotation calls to Yaw and the like actually rotate space about the point
>(0,0,0).  If you have, for example, two cubes located in differnt places in
>space, calls to pitch will rotate BOTH cubes teeter-totter like about the point
>(0,0,0) of space.  I could only imagine setting up SEPERATE 3D grafports for
>each cube and copybitting the two (via XOr) to a single 2D grafport on the
>screen.  Slow.
>
>If anyone has any questions, post them to the net (or mail me I suppose).  I
>can't reply to mail sent to me, but I could post more on a particular aspect of
>Graf3D to the net.
>
>One person mailed me about rotating 3D waveforms and displaying them.  That
>would probably be fairly easy to do given the code I've posted.  Define the
>waveform as a chain of 3D points stretching across the point (0,0,0).  Move the
>eye out away from (0,0,0) but look TOWARD the center of space.  Yaws and Rolls
>will gimble the waveform about.  Redraw (point to point) the waveform after
>each transformation.  You can scale the waveform by simply moving the eye of
>the 3D port toward and away from the center of space.
>
>Cheerio.  I'll check the net for requests.
>
>john calhoun
>
>
>


        Thanks
        Scott [e-mail]



---------------------------

From: [e-mail] (OverLord of Underlings)
Subject: TCL Application projects
Organization: Western Washington University
Date:  6 Feb 92 23:45:52 GMT

I am creating my first full macintosh interface application. It is a
"war-dialer" a modem utility that dials a multitude of phone #s and
records which ones have modems answer. This program will have MANY options
that the plethora of IBM dialers don't as well as a mac interface...

I am new at this, and have chosen this project as my first as it incorporates
many things that I think are necessary to learn sooner or later. Scrolling
lists, dialogs, file input and output, serial drivers etc...

One thing though that I am interested in is the use of the TCL... I am
learning smalltalk at this very moment and loving it, OOP is very intuitive.
Should I convert my current program from C to Thinks OOP with the TCL?

What do you think are the benefits/problems with using TCL?

RWD
_O_
 |




- -------------------------

From: [e-mail] (OverLord of Underlings)
Subject: TCL Application projects II
Organization: Western Washington University
Date:  6 Feb 92 23:51:00 GMT

I would like to see the SMALLEST and simplist appliaction using TCL for
Think C 4.0... if you ahve an example that you think is a good role modal,
please stuff, binhex and mail it to me... I would deeply appreciate having
someone give me a little push in the right direction...

RWD
_O_
 |




- -------------------------

From: [e-mail]
Subject:  TCL Application projects
Date: 10 Feb 92 12:11:57 GMT
Organization: Amherst College, Amherst, MA.

In article <n9146269.697419952@animal>, [e-mail] (OverLord of Underlings) writes:
> I am creating my first full macintosh interface application. It is a
> "war-dialer" a modem utility that dials a multitude of phone #s and
> records which ones have modems answer. This program will have MANY options
> that the plethora of IBM dialers don't as well as a mac interface...
>
>

 Well if I answer my phone and get an annoying beeping noise, I'll
 know whom to blame.





- -------------------------

From:  (Chris Ellens)
Subject:  TCL Application projects
Date: 11 Feb 92 22:26:41 GMT
Organization: Bell-Northern Research

In article <n9146269.697419952@animal>, [e-mail] (OverLord of Underlings) writes:
>
> I am creating my first full macintosh interface application. It is a
> "war-dialer" a modem utility that dials a multitude of phone #s and
> records which ones have modems answer.

For the sake of all of us who answer our phones only to hear the irritating
silence of a modem waiting for carrier.... I hope you never get your first
full mac application working. Who exactly are you at war with, anyway?

..Chris



- -------------------------

Organization: Penn State University
Date: Tuesday, 11 Feb 1992 20:15:54 EST
From: Christopher Tate <[e-mail]>
Subject:  TCL Application projects

In article <n9146269.697419952@animal>, [e-mail] (OverLord of
Underlings) says:
>
>I am creating my first full macintosh interface application. It is a
>"war-dialer" a modem utility that dials a multitude of phone #s and
>records which ones have modems answer. This program will have MANY options
>that the plethora of IBM dialers don't as well as a mac interface...

Be warned:  I've heard it stated that such "war dialers" (named for the
film "War Games," I believe) are illegal in many places, possibly in the
U.S.A. in general.  Corollary: don't mess around with the Phone Company.
If they find you've been calling a large number of telephone numbers for
brief periods of time, they're going to get more than a little upset.

Indeed; many states are making it illegal for telephone solicitations to
use machines to do their message-spouting; they require that there be a
Real Live Human doing the soliciting.

- -----
Christopher Tate     | Cryptogram #11:
[e-mail] |
[e-mail]  | "KOI SDXG EDKZZ QXKS SDXMN EAHNIE MOSH CZHAEDKNXE,
- -------------------|  YHN MY GHV DMS K BKO AMSD K CZHAEDKNX, DX'E UHMOU
Send me the answer!  |  SH TOHA DX'E QXXO DMS."   (QNVFX DHVZS)



---------------------------

From: [e-mail] (Povl Hessellund Pedersen)
Subject: DiskVars / JRdData  ($22E)
Date: 8 Feb 92 01:38:20 GMT
Organization: DAIMI: Computer Science Department, Aarhus University, Denmark

I am currently hacking around in some old code, that will no longer
run on current machines. I am thus trying to remove the check for the
master disk.  MacNosy disassembles something into the label
DiskVar+JRdData  (address is $22E).  TMON Pro lists this as JRdData,
but I would like to know what this global does/is/points to or whatever.
I could not find anything in Inside Mac I-IV.

BTW: This copy protection will also crash on the 68040 based machines,
it contains self modifying code. One place it reserves about 1k of
memory, fills it up with NOP and ending with RTS. Then it calls this
as a subroutine. I guess this is a hack to make the 68030 refill its
instruction cache with the modified code upon return. But it is not
very nice done.
--
Povl H. Pedersen (External student at dept. of CS, student at dept. economics)
Macintosh programmer, consultant and technical support
[e-mail]   /   [e-mail]



- -------------------------

From: [e-mail] (Steve Christensen)
Subject:  DiskVars / JRdData ($22E)
Date: 11 Feb 92 03:40:19 GMT
Organization: Apple Computer Inc., Cupertino, CA

[e-mail] (Povl Hessellund Pedersen) writes:
>I am currently hacking around in some old code, that will no longer
>run on current machines. I am thus trying to remove the check for the
>master disk.  MacNosy disassembles something into the label
>DiskVar+JRdData  (address is $22E).  TMON Pro lists this as JRdData,
>but I would like to know what this global does/is/points to or whatever.
>I could not find anything in Inside Mac I-IV.

Sigh.  Another copy protection scheme bites the dust.  OK, not that I
should talk about it, but the aforementioned location is a vector to
the floppy disk driver's routine to read the data portion of a disk
sector.  Copy protection schemes have often patched that routine
(temporarily) so they can read the disk their own way to determine
if a signature is on the disk.  Note that at least a couple of Macs
ignore that vector, so whatever other skanky things were being done,
reading from the disk wasn't going to be one of them.

steve

--
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
  Steve Christensen            Never hit a man with glasses.
  [e-mail]            Hit him with a baseball bat.



---------------------------

From: [e-mail] (Thomas James Vilot)
Subject: My INIT and cdev don't talk to each other!
Date: 9 Feb 92 21:50:37 GMT
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)


I am having a problem getting an init and cdev to talk
with one another. I want to use Gestalt to create a new
selector code, and have my functionreturn the address of
the data in memory. However, when i do a NewGestalt,i get
an error that the routine is not in the system heap. But I
know itis because that is where it is loading at boot time.

What's the problem?? Is there an easier way to do this?

Thanx in advance.

[e-mail]


--
Thomas J. Vilot        aka: [e-mail]
Jeffersonville, PA    Near Valley Forge, Pennsylvania



- -------------------------

From: [e-mail] (Thomas James Vilot)
Subject: INIT and CDEV communication (was: My Init and cdev...)
Date: 10 Feb 92 22:48:46 GMT
Organization: Case Western Reserve University, Cleveland, Ohio, (USA)


In a prvious post, I asked if anyone knew how to get an INIT and
cdev to talkt to each other. Having not been very explicit about
the problem, I thought I should follow up:


> Why don't you post a code excerpt?  You haven't given us much to work

> with.
> --
>   -- Jim Walker [e-mail]  [e-mail]
>
>

Here is some of the code i am using to try to pass
information between my init and cdev.

the call below is done in the init with the selector
function in the same file.

      NewGestalt(kOurCreat, mySelectorFunction);


      OSErr mySelectorFunction(OSType selector, long *response)
      {
              *response = (long) address_of_data_to_pass;

      }


the routine below is used to get the address of the data.

     Ptr FindInitData()
     {
        long                addr;

        Gestalt(kOurCreat,&addr);
        return((Ptr) addr);

     }


The question is, why does NewGestalt return the an error
which says the routine is not in the system heap??
And is there an easier way to do this (i was using a
little hack that checked the heap for a specific
string, but that breaks in 32bit mode)

Thanx in advance!

Jim Walker, and all, I hope this explains it a little better.
You are all actually getting this post from two people
so this could get confusing. I am forwarding posts for
[e-mail] since Temple University can't
seem to get their damnable act together and get news
posting to work. But, we are both working on this same
project.

--
Thomas J. Vilot                 "Blessings of the masses,
[e-mail]     "Blessings of the State...
Jeffersonville, PA              "Buy. Buy more. Buy now..." -THX1138



- -------------------------

From: [e-mail] (Matthias Ulrich Neeracher)
Subject:  INIT and CDEV communication (was: My Init and cdev...)
Date: 11 Feb 92 16:48:38 GMT
Organization: Integrated Systems Laboratory, ETH, Zurich

In article <[e-mail]> [e-mail] (Thomas James Vilot) writes:
>Here is some of the code i am using to try to pass
>information between my init and cdev.
>
>the call below is done in the init with the selector
>function in the same file.
>
>      NewGestalt(kOurCreat, mySelectorFunction);
>
>
>      OSErr mySelectorFunction(OSType selector, long *response)
>      {
>              *response = (long) address_of_data_to_pass;
>
>      }
>
>
>the routine below is used to get the address of the data.
>
>     Ptr FindInitData()
>     {
>        long                addr;
>
>        Gestalt(kOurCreat,&addr);
>        return((Ptr) addr);
>
>     }
>
>
>The question is, why does NewGestalt return the an error
>which says the routine is not in the system heap??

Probably because the routine *is* not in the system heap. Have you checked that
? By default, INITs are loaded into the application heap, and I wouldn't trust
the resSysHeap flag for things like this.

>And is there an easier way to do this (i was using a
>little hack that checked the heap for a specific
>string, but that breaks in 32bit mode)

This should work if you don't rely on the structure of heap blocks but do a
brute force search (this is not as slow as it sounds). But if Gestalt is
implemented, it is the better way to use.

Matthias

- ---
Matthias Neeracher                                      [e-mail]
 `We say "gestalt" when things combine to act in ways we can't explain'
                             -- Marvin Minsky, _The Society Of Mind_



---------------------------

End of C.S.M.P. Digest
**********************